NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/9921

Internet Message Format | 1996-08-05 | 5.5 KB

Path: goanna.cs.rmit.EDU.AU!not-for-mail
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c
Subject: Re: Hungarian notation - whoops!
Date: 5 Mar 1996 15:22:20 +1100
Organization: Comp Sci, RMIT, Melbourne, Australia
Message-ID: <4hgfhs$[e-mail]>
References: <[e-mail]> <4fc157$[e-mail]> <dewar.823793746@schonberg> <4fms62$[e-mail]> <[e-mail]> <4g9255$[e-mail]> <[e-mail]> <4h6gbp$[e-mail]> <dewar.825776096@schonberg>
NNTP-Posting-Host: goanna.cs.rmit.edu.au
X-Newsreader: NN version 6.5.0 #0 (NOV)

[e-mail] (Robert Dewar) writes:
>Richard O'Keefe said

>"I have implemented multiple-precision arithmetic, and I must say I found
>2s-complement a confounded nuisance.

>This makes me think that you don't understand the point. What you say above
>is that for multiple-precision you need unsigned arithmetic, and that signs
>get in the way.

No, I didn't say that at all.  What I said was that the way _I_ implemented
multiprecision arithmetic >>made use of<< unsigned arithmetic and that signs
would have got in my way.  Obviously all you absolutely >>need<< for
implementing any kind of arithmetic is operations on single bits.  (Think of
the DAP, where floating point arithmetic was implemented by single-bit CPUs.)

>But the whole point is that TWOS COMPLEMENT ARITHMETIC IS
>IDENTICAL TO UNSIGNED (for addition and subtraction).

Wrong.  That is not the whole point.  In fact, it isn't even true on some
machines.  There are machines where signed twos-complement add and subtract
are done by one set of instructions, which raise an exception on overflow,
and unsigned arithmetic is done by another set of instructions, which don't.

In any case, addition and subtraction are hardly the whole of mult-precision
arithmetic.  Multiplication and division and remainder are also required,
and twos complement multiplication division and remainder are most certainly
NOT identical to unsigned.

Mind you, somebody in the GCC crowd appears to think they are.  On a SPARC,
signed integer multiplication is done by the run-time library function .mul
and unsigned integer multiplication is done by .umul.  Here's a C function:

int om(int left, int right) { return left * right ; }

Compile it using LCC and you get

    om:
    save    %sp,-96,%sp
    mov    %i0,%o0
    mov    %i1,%o1
    call    .mul,2
    nop
    mov    %o0,%i0
    ret
    restore

Compile it using SPARCompiler C and you get

    om:
    save    %sp,-96,%sp
    or    %g0,%i1,%o1        ; same as mov %i1,%o1
    call     .mul,2
    or    %g0,%i0,%o0        ; same as mov %i1,%o1
    ret
    restore    %g0,%o0,%o0

But compile it with GCC and you get

    om:
    save    %sp,-112,%sp
    mov    %i0,%o0
    call    .umul,0            ; note .umul,0 instead of .mul,2
    mov    %i1,%o1
    mov    %o0,%i0
    ret
    restore

"The whole point" is that twos-complement arithmetic and unsigned arithmetic
are DIFFERENT (except for addition and subtraction) and here GCC is calling
the _unsigned multiplication_ routine to multiply _signed_ numbers.  In
the SPARC V8 ABI manual, .mul is listed in appendix E.1 and .umul is
listed in appendix E.2.  In fact the functions listed there _do_ report
overflow by setting the Z bit.  For multiplication, you can get away
with using the unsigned multiply as gcc does, but then you lose the
ability to test the Z bit.  (Which matters for the -gnato option.)

>If you had trouble from 2s-complement arithmetic in this context, it must
>have been because you were confused ..

No, it was because I was doing comparison and multiplication and
division as well as addition and subtraction.

In particular, if you are doing 16x16->32 bit multiplication, which is
useful for multiprecision arithmetic, signed multiply and unsigned
multiply give very different answers.

>As for the claim that you don't have to check for overflow in negation,
>that's preetty much irrelevant in practice, since in a properly
>written program with reasonable types, there is no reason that the range
>of your data should correspond to machine ranges anyway.

This is perfectly true *IF* you are using a language that lets you say
what range you want *AND* you are in charge of the interface.  But this
discussion is not confined to comp.lang.ada and I for one hadn't been
considering only small single-author programs.  Robert Dewar also ignores
my specific claim that I had encountered Pascal compilers which failed
to check for overflow after negation or absolute value.

Perhaps we should wind this down.  Clearly this is an area where reasonable
people may differ.  I am quite certain that Robert Dewar and I are agreed
that a well-written program in a well-chosen programming language specifies
the bounds that are appropriate to that program for that problem rather than
blindly accepting some machine size, and that a good compiler will, on
request, generate sufficient run-time checks (I have seen figures that 99+%
of bounds checks can be optimised away) that overflow beyond the declared
range will certainly be trapped.  In such an environment, the fact that the
underlying arithmetic is unpleasant (my view) or wonderful (Dewar's view)
doesn't matter, because the programmer only has to deal with the arithmetic
model of the language, not the machine.

Not all programs can be written in such languages or with the aid of such
compilers, and all too often the machine shows through.

--
The election is over, and Australia lost; the idjits elected _politicians_!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.